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SYSTEM AND METHOD FOR ENABLING ARBITRARY COMPONENTS 



TO TRANSFER DATA BETWEEN EACH OTHER 



FIELD OF THE INVENTION 
[0001] This invention relates generally to communication systems and 

methods and, more particularly, to a system and method for enabling arbitrary 
components to transfer data between each other using one or more universal data 
transfer interfaces employing mobile code. 

BACKGROUND OF THE INVENTION 
[0002] In data communication environments, such as a distributed 

network, many different vendors provide a number of products for specific 
services. Heretofore, a predetermined set of domain specific protocols has been 
required to be specified to enable arbitrary components in the environment to 
communicate with each other, assuming the components were transmitting or 
receiving data, hereinafter referred to as ("transferring data"). For example, a 
device manufactured by one vendor would have difficulty communicating with a 
device manufactured by another vendor without using the predetermined set of 
protocols mentioned above. The problem of different vendors requiring different 
predetermined protocols has been partially dealt with by adopting existing 
protocol standards. However, there are different standards organizations and thus 
different protocol standards. 

[0003] When arbitrary components such as computer applications or 

programs, data, memory, file directories, individual files, printer devices, cellular 
telephones, facsimile machines, copier machines, scanner devices, desk-top 
computers, lap-top computers, personal digital assistant ("PDA") systems, or any 
other device, for example, attempt to communicate without having a priori 
knowledge of each other, particular domain-specific protocols, such as the file 
system domain (e.g., NFS and CEFS) or the printer domain (e.g., IPP and LPR), 
must be known a priori by both parties to successfully communicate. An arbitrary 
component, such as a PDA attempting to communicate with a file system, or a 



printer device attempting to do the same, must be explicitly programmed to 
understand one or more of the standardized protocols mentioned above. An 
example includes a computer device or application having to be programmed to 
understand a printer device by installing a domain-specific printer driver. If the 
device or application is programmed to understand how to communicate and use a 
printer device, genetically, the driver will only enable the device or application to 
access a particular type of printer device and not the universe of all printer 
devices. Thus, when new and unknown components enter the equation, the 
application must be reprogrammed to understand the new standardized protocols 
used to communicate with the new components. Referring to the above computer 
and printer device example, if a new type of printer were introduced, the computer 
device would have to be re-programmed to be able to transfer data with the new 
printer device by installing a printer driver specific to the new printer device. 
Thus, each application must be explicitly written to use a particular set of 
standardized protocols a priori to communicating with the components associated 
with the protocols. 

[0004] In a system such as Jini™, developed by Sun Microsystems of Palo 

Alto, California and described in "A collection of Jini™ Technology Helper 
Utilities and Services Specifications," Palo Alto, California, Sun Microsystems, 
Inc., pp. 1-214, 2000; and "Jini™ Technology Core Platform Specification," Palo 
Alto, California, Sun Microsystems, Inc., pp. 1-126, 2000, all of which are hereby 
incorporated by reference in their entirety, which uses domain-specific interfaces, 
in order for a component such as a PDA system to communicate with another 
component such as a printer, the PDA system must contain a priori knowledge of 
the semantics of the printer's programmatic interfaces. In other words, a 
component that knows how to print still might not know how to transfer data 
between a file system, a scanner device or a network translation service until it is 
explicitly programmed to know how to communicate with the interface for the 
particular components. 
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[0005] A system for enabling components to transfer data between each 

other in accordance with the present invention includes a first component having a 
universal data transfer interface and a second component invoking the universal 
data transfer interface to use a data transfer session object to transfer data between 
5 the first component and at least one of the components. 

[0006] A system for enabling components to transfer data between each 

other in accordance with the present invention includes a first component having a 
first universal data transfer interface, a second component having a second 
universal data transfer interface, and a third component invoking the first universal 
data transfer interface and the second universal data transfer interface to use a data 
transfer session object to transfer data between the first component and the second 
component. 

[0007] A method and a program storage device readable by a machine and 

tangibly embodying a program of instructions executable by the machine for 
enabling components to transfer data between each other in accordance with the 
present invention include invoking a universal data transfer interface to obtain a 
data transfer session object, and using the data transfer session object to transfer 
data between a first component and at least one of the components. 

[0008] A method and a program storage device readable by a machine and 

tangibly embodying a program of instructions executable by the machine for 
enabling components to transfer data between each other in accordance with the 
25 present invention include invoking a first universal data transfer interface and a 

second universal data transfer interface, obtaining a data transfer session object 
from one of the invoked first universal data transfer interface or the second 
universal data transfer interface, and using the data transfer session object to 
transfer data between a first component and a second component. 

30 

[0009] The present invention allows components using the same or 

different communications protocols and/or data types to transfer data between 
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each other without having a priori knowledge of any domain-specific interfaces, 
protocols or data formats. In addition, the invention enables components to 
initiate data transfer sessions between other components. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0010] FIG. 1 is a diagram of a system for enabling arbitrary components 

to transfer data between each other in accordance with one embodiment; 

[001 1 ] FIG. 2 is a block diagram of an exemplary arbitrary component 

utilized in the system for enabling arbitrary components to transfer data between 
each other; 

[0012] FIG. 3 is a diagram of a system for enabling one arbitrary 

component to receive data from another arbitrary component in accordance with 
another embodiment; 

[0013] FIG. 4 is a flow chart of a process for receiving data from another 

arbitrary component; 

[0014] FIG. 5 is a diagram of a system for enabling one arbitrary 

component to transmit data to another arbitrary component in accordance with 
another embodiment; 

[0015] FIG. 6 is a flow chart of a process for transmitting data to another 

arbitrary component; 

[0016] FIG. 7 is a block diagram of a system where one arbitrary 

component enables two other arbitrary components to transfer data between each 
other in accordance with another embodiment; and 

[0017] FIG. 8 is a flow chart of a process where an arbitrary component 

enables other arbitrary components to transfer data between each other. 



DETAILED DESCRIPTION OF THE INVENTION 
[0018] A system 1 0 for enabling arbitrary components to transfer data 

between each other in accordance with one embodiment of the present invention is 
shown in FIG. 1 . In this particular embodiment, system 10 includes computer 20, 
printer 21, personal digital assistant ("PDA") 22, server 23 and facsimile machine 
24 ("components 20-24"). A method in accordance with one embodiment 
includes computer 20 obtaining one of the universal data transfer interfaces (i.e., 
the data source interface or the data sink interface) associated with one or more of 
components 21-24, and invoking the one or more obtained universal data transfer 
interfaces to transfer data between components 20-24. The present invention 
allows components 20-24 using the same or different communication protocols 
and/or data types to transfer data between themselves without having a priori 
knowledge of any domain-specific interfaces, protocols or data formats. The 
present invention also enables components 20-24 to initiate data transfer sessions 
between other components 20-24. 

[0019] Referring more specifically to FIG. 1, computer 20 is operatively 

coupled to each of the components 21-24 in this particular embodiment, although 
other coupling arrangements or configurations can be used as well as greater or 
lesser numbers of components. For example, system 10 could comprise one or 
more of the components 21-24 directly coupled to one or more of the other 
components 21-24 (e.g., a peer-to-peer system) or system 10 could comprise 
components 20 and 21, which are coupled together. 

[0020] A conventional dial-up communication system through private 

branch exchanges ("PBX") and using public switched telephone lines and line 
based telephone communication protocols may be used by components 20-24 to 
communicate with each other. Although one type of communication system and 
protocol is shown, a variety of different types of communication systems and/or 
protocols may be used. For example, communication systems or network 
architectures, such as local area networks ("LAN"), wide area networks ("WAN") 



and cellular or satellite communications network systems that utilize signals, such 
as satellite signals, radio waves, microwaves and/or infrared signals, can be used. 
Additionally, a variety of communication protocols for transferring data, such as 
xDSL, ISDN, TCP/TP or protocols defined by the RFC and OSI organizations can 
also be used. The type of protocol used will depend upon the type of 
communication system being used by a particular component, the type of 
component (e.g., a printer device or a scanner device) and/or the type of network 
environment the component is operating in (e.g., the UNIX operating 
environment). Components 20-24 may use one or more communications 
protocols. Moreover, the arrows in FIG. 1 depict the flow of communications 
between components 20-24. 

[0021] Referring to FIG. 2, in this embodiment, computer 20 comprises a 

central processing unit ("CPU") 30, memory 32 and VO unit 34, which are 
coupled together by a bus 36, although computer 20 may comprise any type of 
device or system that can store, process and execute instructions for performing 
one or more methods of the present invention. By way of example only, computer 
20 may also comprise a scanner, cellular telephone, display device, video 
input/output device, audio input/output device, remote control device or an 
appliance. Computer 20 could also comprise any type of device with circuitry that 
is hard-wired to execute instructions for performing one or more methods of the 
present invention. Computer 20 executes instructions for an operating system 
environment it is operating in, such as the UNIX® environment, as described in 
"Advanced Programming in the UNIX® Environment," W. Richard Stevens, 
Addison- Wesley Publishing Company, 1974, which is hereby incorporated by 
reference in its entirety. In this embodiment, computer 20 does not use the same 
communication protocol as any of the other components 21-24, but in other 
embodiments computer 20 does use the same communication protocol as any of 
the other components 21-24. By way of example only, computer 20 may be 
operating in the UNIX® environment using a first type of communication protocol 
to transfer data, while printer 21 may be operating in a Microsoft Windows® 
environment, but using a second type of communication protocol. 



[0022] CPU 30 may comprise a processor, such as an Intel Pentium HI 

processor. The CPU 30 executes at least one program of stored instructions for a 
method for enabling arbitrary components to transfer data between each other in 
accordance with the present invention as described and illustrated herein. CPU 30 
may also execute instructions for other tasks, including network services, such as 
providing data, memory, file directories, individual files, word processing 
applications, accounting applications or engineering applications. As a result, 
when one of these applications is executed, the instructions for the task, such as 
for creating a spreadsheet, as well as the instructions for performing one or more 
of the methods of the present invention are carried out by the CPU 30 in computer 
20. The instructions may be expressed as executable programs written in a 
number of computer programming languages, such as BASIC, Pascal, C, C++, C#, 
Java, Perl, COBOL, FORTRAN, assembly language, machine code language, or 
any computer code or language that can be understood and performed by the CPU 
30. 

[0023] Memory 32 may comprise any type of fixed or portable memory 

device accessible by the CPU 30, such as hard-disks, floppy-disks, compact disks 
("CD"), digital video disks, magnetic tape, optical disk, ferroelectric memory, read 
only memory, random access memory, electrically erasable programmable read 
only memory, flash memory, erasable programmable read only memory, static 
random access memory, dynamic random access memory, ferromagnetic memory, 
charge coupled devices, smart cards, or any other type of computer-readable 
mediums. Memory 32 stores instructions 38 for a method of enabling arbitrary 
components to transfer data between each other in accordance with one 
embodiment of the present invention for execution by CPU 30, although some or 
all of these instructions can be stored elsewhere. One or more sets of universal 
interfaces or data objects may be stored in memory 32 so they can be retrieved as 
needed by the CPU 30 during operation of the present invention as will be 
described in further detail herein. Although in this embodiment the CPU 30 and 



memory 32 are shown in the same physical location, they may be located at 
different physical locations, such as in server 23 shown in FIG. 1. 

[0024] Computer 20 may communicate with components 2 1 -24 using I/O 

unit 34. In this embodiment, I/O unit 34 may comprise a router such as any type 
of Ethernet based device having sufficient ports to operatively couple computer 20 
to components 21-24. 

[0025] Referring back to FIG. 1, printer 21 comprises a conventional 

printing device capable of rendering graphical representations on a printing 
medium, for example. Since devices such as printer 21 are well known in the art, 
the specific elements, their arrangement within printer 21 and operation will not 
be described in detail here. 

[0026] PDA 22 comprises a conventional hand held device that may 

perform such functions as telephony, facsimile transmissions or networking. 
Since devices such as PDA 22 are well known in the art, the specific elements, 
their arrangement within PDA 22 and operation will not be described in detail 
here. 

[0027] Server 23 comprises a conventional computer system having one or 

more CPU's, memory, I/O units and one or more storage mediums, which are 
coupled together by a bus and used by server 23 to store and process instructions 
in accordance with one or more embodiments of the present invention as described 
further herein. Since devices such as server 23 are well known in the art, the 
specific elements, their arrangement within server 23 and operation will not be 
described in detail here. 

[0028] Facsimile machine 24 comprises a conventional facsimile device 

that can send and receive pictures or text over a telephone line or network. Since 
devices such as facsimile machine 24 are well known in the art, the specific 



elements, their arrangement within facsimile machine 24 and operation will not be 
described in detail here. 

[0029] Referring to FIG. 3, computer 20 is coupled to PDA 22 as 

described above in connection with FIG. 1. PDA 22 has stored in a memory, or 
otherwise has access to by accessing server 23, for example, which will hereinafter 
be referred to as being "associated with," a set of universal interfaces 22a 
comprising a data source interface, a contextual interface, a notification interface 
and a user interface. The particular number and/or combination of interfaces may 
vary and will depend upon the particular type of device PDA 22 is, and the 
capabilities and/or services desired or provided by it. Also, PDA 22, and hence 
the set of universal interfaces 22a, may be updated at any time to add, delete or 
modify interfaces. Further, computer 20 is programmed to access the interfaces 
associated with PDA 22. Likewise, PDA 22 could access one or more interfaces 
(not illustrated) associated with computer 20. 

[0030] Computer 20 may access the set of universal interfaces 22a through 

data object 22b to effect different types of communications as described herein. 
Each of the interfaces in the set of universal interfaces 22a comprise instructions, 
sets of operations and/or other data that can be understood and performed by 
computer 20 to enable it to communicate and transfer data (i.e., transmitting or 
receiving data) with PDA 22, exchange contextual information with PDA 22, 
provide computer 20 with event notifications for PDA 22, or enable computer 20 
to receive user interfaces to allow users of computer 20 to access and/or 
manipulate PDA 22. hi general, each interface in the set of universal interface 22a 
is not domain-specific with respect to PDA 22. 

[0031] In particular, the data source interface includes several operations 

such as a getSourceDataFlavor() operation and a beginTransferSession() 
operation. Further, the data source interface includes instructions and data that 
can be performed by computer 20 to establish a data transfer session to enable 
computer 20 to receive data from PDA 22. The getSourceDataFlavor() operation 
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includes instructions and data that may be performed by computer 20 for 
determining the types of data PDA 22 can transmit. In this particular embodiment, 
computer 20 performs the getSourceDataFlavor() operation that returns a list of 
one or more data types supported by PDA 22. Moreover, the data types in this 
embodiment are typically MIME data types. For example, after performing the 
above-mentioned operations, computer 20 may determine that PDA 22 supports 
data in a "JPEG" format. The beginTransferSession() operation includes 
instructions and data that maybe performed by computer 20 to request PDA 22 to 
establish a data transfer session to receive data by returning a data transfer session 
object 22c to computer 20 through data object 22b. Moreover, the 
beginTransferSession() operation may be passed parameters when invoked such as 
a context parameter, an initial lease duration parameter and a data flavor 
parameter, hi this embodiment, computer 20 passes a context parameter to the 
beginTransferSession() operation when invoking it to inform PDA 22 of its 
identity for a variety of reasons, such as for identifying computer 20 to PDA 22, 
identifying a user at computer 20 to PDA 22, identifying the location of computer 
20 on a network to PDA 22 or for security purposes. PDA 22 may decide whether 
to transmit data to computer 20 based upon the identity information provided in 
the context parameter. Further, data transfer sessions are leased and would thus 
need to be renewed periodically by computer 20 at intervals of time corresponding 
to a value specified in the initial lease duration parameter passed to the 
beginTransferSessionO operation to keep the data transfer session active, although 
in other embodiments the sessions need not be leased. Where sessions are leased, 
if computer 20 fails to renew the lease PDA 22 will stop transmitting data to 
computer 20 under the assumption that computer 20 has failed to renew the lease 
because it has either crashed or has otherwise become unreachable, hi addition, if 
PDA 22 supports one or more types of data, as determined by performing the 
getSourceDataFlavor() operation, a data flavor parameter may be passed into the 
beginTransferSessionO operation. Computer 20 may provide a preferred data type 
value to the data flavor parameter for a number of reasons, such as in the event 
computer 20 and PDA 22 support multiple, compatible data types where computer 
20 specifies, using the parameter, a preferred data type for the data transfer. In this 
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embodiment, computer 20 may determine a preferred data type using a number of 
methods such as enabling users at computer 20 to indicate preferred data types, 
randomly selecting one of the compatible data types between computer 20 and 
PDA 22 or selecting the data type that will be most efficient for the particular data 
being transferred. 

[0032] The contextual interface comprises a getContext() operation that 

includes instructions and data that can be performed by computer 20 for retrieving 
contextual information from PDA 22. In this embodiment, the contextual 
information is stored in a memory at PDA 22 as a multi-valued data structure that 
resembles a hash table, although the contextual information can be stored in any 
other format. Also in this embodiment, the contextual information includes 
information about PDA 22 such as what type of device it is, its operating status, 
identity, location, administrative domain, or any other type of environment data, 
hi another embodiment, the contextual information may be stored at another 
physical location such as server 23. 

[0033] The notification interface includes a register() operation, which 

may be passed one or more parameters and performed by computer 20 to enable it 
to receive asynchronous notifications about events generated by PDA 22, although 
it may receive synchronous notifications as well. Computer 20 performs the 
register() operation, passing to it a context parameter, a component parameter and 
an initial lease duration parameter. The context parameter provides PDA 22 with 
the identity of computer 20 for a number of reasons, such as enabling PDA 22 to 
decide whether it would desire sending notifications to computer 20 for security 
purposes or record keeping. The component parameter identifies computer 20 as 
desiring to be notified of events occurring at PDA 22. Further, event registrations 
are leased and must be renewed periodically by computer 20 at intervals of time 
corresponding to the value specified in the initial lease duration parameter to keep 
the event registration active. If computer 20 fails to renew the lease, the 
notification interface includes instructions for relieving PDA 22 of its obligation 
to provide computer 20 with notifications about generated events since it will 
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assume that computer 20 has failed to renew the lease because it has either crashed 
or has otherwise become unreachable. Once computer 20 has registered itself with 
PDA 22 by performing the register() operation, if a condition occurs in PDA 22 
that should cause it to notify computer 20 according to the instructions provided in 
5 the notification interface and associated operations, PDA 22 will send an event 

notification object to computer 20. Computer 20 may then generate a user 
window, as described further herein below, to display the event information to a 
user. For example, if PDA 22 instead was a printer device and computer 20 
1-4: instead was a word processing application, PDA 22 would be able to provide 

S 1 0 computer 20 with an event notification in the case where paper in the printer 

device jammed. Moreover, in this example, computer 20 could display the event 

ft} 

fU notification (i.e., paper jam) to the user using a graphical user interface ("GUI"). 

If! 

m 

[0034] The user interface comprises a getUI(), getState() and setStateO 

N 1 5 operation that includes instructions and data that can be performed by computer 20 

\q for retrieving or generating a user window specific to PDA 22 to provide users of 

;. ! computer 20 with so they can access and/or manipulate PDA 22 to take advantage 

of additional functionality of PDA 22. In this embodiment, the getUI() operation 
can be passed parameters when invoked by computer 20 to indicate which type of 
20 user window the user would like generated, as described in further detail herein. 

The getUI() operation returns to computer 20, from PDA 22, a user window and/or 
instructions for generating or retrieving a user window, which may be instantiated 
by computer 20 to display the user window to users, for example. The getState() 
operation includes instructions and data for requesting that a state token object be 
25 returned to computer 20 from PDA 22. The state token object may be an opaque 

object with respect to computer 20, which is particular to PDA 22 and further may 
encapsulate the current state (e.g., device settings or configuration) of PDA 22, 
although the state token object may be transparent with respect to computer 20 in 
a case where computer 20 is able to understand the state token object of PDA 22. 
30 Further, PDA 22 may use different types of state token objects depending upon the 

particular type of device it is (e.g., a printer device or word processing 
application). Still further, PDA 22 may encode its respective state token objects in 
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various ways, such as pointers or URLs pointing to particular configurations. 
Alternatively, the state token objects may include a representation of the current 
state of PDA 22. Additionally, the setState() operation includes instructions and 
data that may be performed by computer 20 for generating the user window using 
the configuration data included in the state token object. Computer 20 may pass 
the state token object as a parameter to the setState() operation when it is invoked, 
which can be used by PDA 22 to return instructions and data that can be 
performed by computer 20 for retrieving or generating the user window having the 
stored configuration included in the state token object. The setState() operation 
may also be invoked by computer 20 to reset the state of PDA 22 without having 
to recreate the user window for the user. 

[0035] Each of the above-described interfaces and associated operations 

therein, as well as any others that may be subsequently described herein, comprise 
mobile code. Mobile code is executable data that can be transmitted to computer 
20 where it is executed. For example, Java is an implementation of executable 
content (i.e., mobile code) that is widely used on the Internet. Users can download 
the mobile code from the Internet, for example, and locally run a program written 
in a truly common programming language. In this embodiment, the mobile code 
is object oriented mobile code, which is a programming methodology that is well 
known in the programming arts, where data types may be defined along with 
associated procedures or sets of instructions, the data types in this context often 
referred to as classes. Thus, a set of procedures or instructions may be associated 
with one or more data types. Moreover, the same name or identifier can be 
assigned to identify a procedure or a set of instructions that perform corresponding 
instructions depending upon the particular data types associated therewith, often 
referred to as polymorphism. Thus, for exemplary purposes only, a draw 
procedure could be performed to draw circles or rectangles depending upon the 
type of data provided, or passed, to the procedure when it is invoked. Further in 
this example, if a circle data type defines a radius coordinate, for example, and a 
draw procedure is invoked and the circle data type is passed to the draw 
procedure, the draw procedure, inheriting any other data types associated with the 
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draw procedure, can use the data provided thereto to perform the appropriate 
procedure or sets of instructions to draw a circle. In this embodiment, when the 
set of universal interfaces 22a is provided to computer 20, the procedures, sets of 
instructions and other data associated with the particular interface become 
available to computer 20 to access and perform, as will be described further 
herein. Moreover, variables, parameters and data may be passed or provided to 
the universal interfaces that will be understood and utilized accordingly by 
computer 20, depending upon the particular type of communication desired. Still 
further, the interfaces may comprise sets of instructions or references to other 
interfaces, wherein computer 20 could utilize the data or perform the instructions 
accordingly. 

[0036] Computer 20 may also directly access each of the interfaces 

included in the set of universal interfaces 22a without needing to obtain data 
object 22b to effect the different types of communications described herein. 
Moreover, each of the interfaces in the set of universal interfaces 22a would 
comprise the same instructions, sets of operations and/or other data that could be 
understood and performed by computer 20 to enable it to communicate and 
transfer data with PDA 22 as well as the other functions described above. 
Therefore, mobile code may not be required in this example, although it could be 
used as necessary such as where data is being transferred. 

[0037] In this embodiment, data object 22b is received from PDA 22 and 

stored in computer 20, although the data object 22b could be stored elsewhere, 
such as server 23. The set of universal interfaces 22a is accessible to computer 20 
through the data object 22b. More specifically, data object 22b supports the 
various operations defined by the interfaces associated with PDA 22, which are 
assumed to be known and understood by computer 20. The data object 22b 
comprises instructions (i.e., computer executable code) and/or data that provide 
particular implementations of the one or more interfaces associated with the PDA 
22 from which the data object 22b is associated with. For example, data object 
22b as provided by PDA 22 to computer 20 would provide a custom 
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implementation of the data source interface that would be specialized to 
communicate with PDA 22 using whichever protocols and/or data formats have 
been decided upon by the developer of PDA 22. 

[0038] hi this embodiment, the data transfer session object 22c includes a 

getTransferData() operation, a getDataSource() operation, an abort() operation, a 
fail() operation, a completed() operation, the register() operation associated with 
the notification interface described above, a getLease() operation, a getViewer() 
operation, a getEditor operation, a getPrinter() operation, as well as any other 
instructions needed to enable computer 20 to receive data from PDA 22, including 
protocols for video or file transfer, for example, which may depend upon the type 
of data being received. Data transfer session object 22c includes the above- 
mentioned operations and instructions that are particular to PDA 22, but may be 
performed by computer 20 to receive data, hi an embodiment where computer 20 
(i.e., a data sink component) receives data from PDA 22 (i.e., a data source 
component), for example, computer 20 invokes the getDataTransfer() operation to 
actually retrieve the data from PDA 22. Further, computer 20 may invoke the 
getDataSource() operation to determine the identity and other attributes of PDA 
22. Computer 20 may also invoke the getDataSource() operation to determine 
whether it should modify its behavior during data transfers or whether it should 
even allow certain data transfers to occur. 

[0039] In this embodiment, computer 20 does not need to know details 

with respect to how to receive and understand the data sent from the PDA 22 
through the data transfer session object 22c. In particular, the instructions and 
various operations included within data transfer session object 22c include 
information regarding the specific protocols, mediums and types of data that are 
particular to PDA 22, which may be executed by computer 20 to be able to receive 
and understand data transferred from PDA 22, even though PDA 22 may utilize 
different protocols, mediums or types of data. Furthermore, data transfer session 
object 22c includes instructions for enabling computer 20 to negotiate with PDA 
22 during the transfer of data to select a communications protocol or medium to 
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use to transfer data between each other based upon the type of data being 
transferred. The instructions may also enable computer 20 and PDA 22 to 
negotiate with each other for using different protocols for the data transfer session 
based upon the type of data being transferred. Moreover, the instructions may 
enable computer 20 to modify the format or the content of data being transferred 
through the data transfer session object 22c to convert the data as necessary from a 
first data transfer protocol associated with computer 20 to a second data transfer 
protocol associated with PDA 22. For example, if PDA 22 is transferring 
streaming video to computer 20, then it may be more efficient for PDA 22 to 
transfer the data using compression or progressive encodings. Computer 20 could 
perform the instructions and operations included within data transfer session 
object 22c so that the data transfer session object 22c negotiates with computer 20 
to decide upon the particular protocol to use for the data transfer session, and in 
turn provide computer 20, through data transfer session object 22c, with the 
operations, instructions and data necessary to enable computer 20 to retrieve and 
understand the data transferred through the data transfer session object 22c. 
Further, computer 20 and PDA 22 may negotiate on a preferred physical transport 
medium, if one is available. For instance, if a shared Fire Wire, IR or a Bluetooth 
connection is found to link computer 20 and PDA 22 together it could be used 
instead of an Ethernet connection as the physical transport medium to transfer the 
data. The instructions may also include operations for scaling down data rates 
over slow data transmission links, or may include operations for increasing 
redundancy in the face of errors during a data transfer session. 

[0040] Moreover, data transfer session object 22c may include instructions 

that may be performed by computer 20 to enable it to view the type of data being 
transferred through data transfer session object 22c. For instance, where computer 
20 is not programmed or configured to display "JPEG" image files, or streaming 
video data transfers transmitted from PDA 22, for example, computer 20 may 
perform the instructions included in data transfer session object 22c to view, on a 
display device associated with computer 20, for example, the data being 
transferred. In particular, data transfer session object 22c may include a 
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getViewer() operation that returns a viewer object when the operation is invoked 
by computer 20. The viewer object is specific to the particular type of data that is 
understood and used by PDA 22. Further, the viewer object may include the same 
instructions described above for providing computer 20 with a user interface 
except that the instructions, when performed by computer 20, enable computer 20 
to view the data being transferred. The viewer object may also include 
instructions for enabling computer 20 to view the particular data type associated 
with PDA 22 and being transferred despite computer 20 not being previously 
programmed to view such types of data. In addition, the getViewer() operation 
may be passed parameters, as described above with respect to the user interface, 
for enabling computer 20 to specify the type of user window (i.e., graphical or 
speech) computer 20 would like to display. In this embodiment, the getViewer() 
operation may be stored in PDA 22 and accessible to computer 20 through data 
object 22b. Alternatively or in addition, the getViewer() operation may be stored 
in a central repository, such as in server 23 (FIG. 1). In this example, the server 23 
may store one or more getViewer() operations, where each operation includes 
instructions for enabling computer 20 to view a particular type of data. It should 
be appreciated that the terms "view" or "display" in this embodiment may 
encompass other forms of output, such as where the instructions in data transfer 
session object 22c enable computer 20 to play an audio file in a particular format 
through an audio output device such as a speaker. Furthermore, data transfer 
session object 22c may include additional operations, such as a getEditor() 
operation and a getPrinter() operation, which have the same instructions as the 
getViewer() operation except the getEditor() operation and the getPrinter() 
operation include instructions for enabling computer 20 to edit or print, 
respectively, data being transferred, regardless of whether computer 20 has been 
programmed to understand the particular type of data associated with PDA 22. 
Thus, in this embodiment computer 20 would not need to understand all of the 
types of data formats it may encounter in a data transfer session because the 
instructions to understand such data may be included in data transfer session 
object 22c. It should be noted that computer 20 at least has the capability of 
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executing the various instructions and operations included within data transfer 
session object 22c. 

[0041] hi this embodiment, the abort() operation includes instructions that 

enable computer 20 to terminate the data transfer session with PDA 22. Further, 
computer 20 may indicate to PDA 22 that a data transfer session has failed or has 
been completed by performing the fail() operation or the complete() operation, 
respectively, hi the event that a data transfer session between computer 20 and 
PDA 22 has failed, completed, or aborted, listeners at components 20-24 who 
expressed an interest in the status of the data transfer session by registering will be 
notified of the event through the register() operation. A signaling protocol enables 
computer 20 to indicate when computer 20 has completed using the data transfer 
session object 21c in the case where PDA 22 cannot automatically determine 
when computer 20 is finished such as where the data transfer session has an 
indeterminate duration (e.g., streaming video). The getLease() operation enables 
computer 20 to renew the lease according to the initial lease duration parameter to 
ensure the data transfer session remains active. 

[0042] Referring to FIG. 4 at step 40, computer 20 performs a discovery 

process to determine whether computer 20 and PDA 22 can transfer data between 
each other. In this embodiment, computer 20 discovers PDA 22 using a variety of 
discovery systems such as the Bluetooth™ Service Location Protocol ("SLP") 
developed by Bluetooth SIG, inc., described in "Specification of the Bluetooth 
System," Version 1.1 core, Bluetooth Consortium 2001, the Universal 
Description, Discovery, and Integration Protocol ("UDDI"), developed by the 
Ariba, IBM and Microsoft Corps., described in "UDDI Technical Whitepaper," 
Universal Description, Discovery, and Integration Consortium, pp. 1-12, 2000; 
"Universal Description, Discovery and Integration Data Structure Reference V 
1.0," Ariba, Inc., International Business Machines Corporation and Microsoft 
Corporation, pp. 1-31, 2000; "Universal Description, Discovery and Integration 
Programmer's API 1.0," Ariba, Inc. and International Business Machines 
Corporation and Microsoft Corporation, pp. 1-67, 2000; and "Universal 
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Description, Discovery and Integration Technical White Paper," Ariba, Inc., 
International Business Machines Corporation and Microsoft Corporation, pp. 1- 
12, 2000, the various Jini™ system discovery protocols or simple lookup in a 
name server, for example, all of which are hereby incorporated by reference in 
their entirety. Discovered PDA 22 returns data object 22b to computer 20. 
Computer 20 may introspect the received data object 22b to determine which one 
or more interfaces are associated with PDA 22. Thus, upon computer 20 
performing the above-described discovery and receiving data object 22b from 
PDA 22, computer 20 introspects the received data object 22b to determine which 
universal interfaces PDA 22 is associated with. Computer 20 determines that 
PDA 22 is at least associated with a data source interface, and thus PDA 22 can 
provide it with data. Computer 20 invokes the data source interface associated 
with PDA 22 and included in data object 22b, which includes instructions that 
instruct computer 20 to perform the getSourceDataFlavors() operation included in 
data object 22b. The getSourceDataFlavorsO operation in turn includes 
instructions for accessing PDA 22 to provide computer 20 with the types of data 
supported by PDA 22. 

[0043] Next, at step 42 computer 20 performs the beginTransferSession() 

operation included in the data source interface. In addition, the 
beginTransferSession() operation when invoked may be passed the context 
parameter, the initial lease duration parameter and the data flavor parameter. PDA 
22 returns the data transfer session object 22c to computer 20. Computer 20 may 
determine a preferred data type using the methods described above and provide a 
preferred data type value to receive the data in to the data flavor parameter, 
otherwise computer 20 will receive the data in whichever data format it is 
provided in by PDA 22. Computer 20 may receive data from PDA 22 by way of 
the data transfer session object 22c. 

[0044] Next, at step 44 data transfer session object 22c includes the 

getTransferData() operation and the other operations and instructions described 
above that may be performed by computer 20 to retrieve data from PDA 22. The 
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data is transferred from PDA 22 to computer 20 through data transfer session 
object 21c at step 46. Still further, computer 20 may be able to view data types 
that it is not natively programmed to understand. When computer 20 performs the 
beginTransferSession() operation, PDA 22 may return the instructions, operations 
5 or data directly to computer 20 to enable it to understand the data being transferred 

from PDA 22. 

[0045] Referring to FIG. 5, computer 20 is coupled to facsimile machine 

24 as described above in connection with FIG. 1. Facsimile machine 24 has stored 
in a memory, or otherwise has access to by accessing server 23, for example, a set 
of universal interfaces 24a comprising a data sink interface, which will be 
described in further detail herein. However, facsimile machine 24 may be 
associated with any number of interfaces and in any combination. 

[0046] Facsimile machine 24 may access the set of universal interfaces 24a 

through data object 24b to effect different types of communications. Each of the 
interfaces in the set of universal interfaces 24a comprise instructions, sets of 
operations and/or other data that can be understood and performed by computer 20 
to enable it to communicate and transfer data with facsimile machine 24. Except 
for the data sink interface, each of the interfaces mentioned above are the same as 
those described above in connection with PDA 22, but each interface includes 
instructions that are specific to the particular device they are associated with (i.e., 
facsimile machine 24). 

25 [0047] In particular, the data sink interface includes several operations 

such as a getSinkDataFlavor() and a Transfer() operation. Further, the data sink 
interface includes instructions and data that can be performed by computer 20 for 
establishing a data transfer session to enable computer 20 to transmit data to 
facsimile machine 24. In particular, the getSinkDataFlavor() operation includes 

30 instructions and data that may be performed by computer 20 for determining 

which types of data facsimile machine 24 can support. In this particular 
embodiment, computer 20 may perform the getSinkDataFlavorQ operation which 
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returns a list of one or more data types supported by facsimile machine 24. 
Moreover, the data types in this embodiment are typically MIME data types. The 
Transfer() operation includes instructions and data that may be performed by 
computer 20 to request facsimile machine 24 to establish a data transfer session so 
computer 20 can begin transmitting data to facsimile machine 24. The Transfer() 
operation may be passed parameters in this embodiment when invoked such as 
data transfer session object 20c associated with computer 20, a context parameter 
and a data flavor parameter, hi particular, computer 20 passes the data transfer 
session object 20c into the Transfer() operation to make it available to facsimile 
machine 24 so it may perform the instructions therein to actually receive the data 
from computer 20. In this embodiment, the data transfer session object 20c 
associated with computer 20 includes the same types of instructions, data and 
operations as data transfer session object 22c described above, except that the 
instructions, data and operations included therein are particular to computer 20. 
Computer 20 passes a context parameter into the TransferO operation when 
invoking it to inform facsimile machine 24 of its identity for a variety of reasons, 
such as for security purposes. Facsimile machine 24 may decide whether to allow 
computer 20 to transmit data to it based upon the identity information provided in 
the context parameter. In addition, if facsimile machine 24 supports one or more 
types of data, as determined by performing the getSinkDataFlavor() operation, a 
data flavor parameter may be passed into the Transfer() operation to inform 
facsimile machine 24 the type of data that will be transmitted by computer 20. 
Moreover, computer 20 may provide a preferred data type value to the data flavor 
parameter for a number of reasons, such as in the event computer 20 and facsimile 
machine 24 support multiple, compatible data types where computer 20 specifies, 
using the parameter, a preferred data type for the data transfer. In this 
embodiment, computer 20 may determine a preferred data type using a number of 
methods such as enabling users at computer 20 to indicate preferred data types, 
randomly selecting one of the compatible data types between computer 20 and 
facsimile machine 24 or selecting the data type that will be most efficient for the 
particular data being transferred. Additionally, where computer 20 and facsimile 
machine 24 support a finite number of compatible data types with respect to each 
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other, computer 20 may select the compatible data type to transmit the data to 
facsimile machine 24. 

[0048] Referring to FIG. 6, at step 50 computer 20 performs the discovery 

process and determines by introspecting data object 24b, as described above in 
connection with one or more embodiments, that computer 20 and facsimile 
machine 24 can transfer data between each other because facsimile machine 24 is 
at least associated with a data sink interface. Computer 20 invokes the data sink 
interface associated with facsimile machine 24 and included in data object 24b, 
which includes instructions that instruct computer 20 to perform the 
getSinkDataFlavorO operation. The getSinkDataFlavor() operation in turn 
includes instructions for accessing facsimile machine 24 to provide computer 20 
with the types of data supported by facsimile machine 24, as described above. 

[0049] Next, at step 52 computer 20 performs the Transfer() operation 

included in the data sink interface. In addition, computer 20 passes into the 
Transfer() operation data object 20c, the context parameter and the data flavor 
parameter when invoked as described above. 

[0050] Next, at step 54 facsimile machine 24 performs the instructions 

included within data transfer session object 20c as provided to it through the 
Transfer() operation to receive data from computer 20. The data is transferred 
from computer 20 to facsimile machine 24 by way of data transfer session object 
20c at step 56. 

[0051] Referring to FIG. 7, computer 20, printer 2 1 and server 23 are 

coupled to each other as described above in connection with FIG. 1. In this 
embodiment, printer 21 is associated with a set of universal interfaces 21a 
comprising a data source interface, a data sink interface and a contextual interface. 
Server 23 is associated with a set of universal interfaces 23a comprising a data 
source interface, a data sink interface and a contextual interface. Each of the 
interfaces mentioned above are the same as those described above in connection 
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with FIGS. 3 and 5, except that each interface in this embodiment includes 
instructions that are specific to the particular device they are associated with (i.e., 
printer 21 or server 23). Moreover, the data transfer session object 25 associated 
with printer 21 includes the same instructions, data and operations as data transfer 
session objects 20c and 22c as described above, except that the instructions, data 
and operations included therein are particular to printer 21 . 

[0052] Referring to FIG. 8, at step 60 computer 20 performs the discovery 

process and determines by introspecting data objects 21b and 23b, as described 
above in connection with one or more embodiments, that printer 21 and server 23 
can transfer data between each other because printer 21 is associated with a data 
source interface and server 23 is associated with a data sink interface. Computer 
20 invokes the data source interface associated with printer 21 and performs the 
getSourceDataFlavorsO operation included in data object 21b to access printer 21 
to determine the types of data supported by printer 21, as described above. 

[0053] Next, at step 62 computer 20 performs the beginTransferSession() 

operation included in the data source interface. In addition, the 
beginTransferSession() operation may be passed the context parameter associated 
with computer 20 or server 23. For instance, computer 20 may invoke the 
contextual interface associated with server 23 and accessible through data object 
23b. In this example, computer 20 would receive the contextual information from 
server 23 but in turn provide it to printer 21 through the beginTransferSession() 
operation. This enables printer 21 to decide whether it would like to transfer the 
data with server 23. Alternatively, computer 20 may provide its own contextual 
information to printer 21 for the same reasons as well as the initial lease duration 
parameter when invoked as described above. Computer 20 invokes the data sink 
interface associated with server 23 and included in data object 23b, which includes 
instructions that instruct computer 20 to perform the getSinkDataFlavorO 
operation. The getSinkDataFlavorO operation in turn includes instructions for 
accessing server 23 to provide computer 20 with the types of data supported by 
server 23. In addition, if server 23 supports one or more types of data, as 
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determined by performing the getSinkDataFlavor() operation, a data flavor 
parameter may be passed into the Transfer() operation to inform server 23 the type 
of data that will be transmitted to it. Moreover, computer 20 may provide a 
preferred data type value to the data flavor parameter for a number of reasons, 
such as in the event printer. 21 and server 23 support multiple, compatible data 
types where computer 20 specifies, using the parameter, a preferred data type for 
the data transfer between printer 21 and server 23. Printer 21 returns the data 
source object 25 to computer 20 through data object 21b. 

[00541 Next, at step 64 computer 20 performs the Transfer() operation 

included in the data sink interface associated with server 23 and included in data 
object 23b. The Transfer() operation may also be passed parameters when 
invoked, including the data source object 25 received by computer 20 from printer 
21, a context parameter and/or the data flavor parameter associated with printer 
21 . Computer 20 provides to server 23 the context parameter associated with 
computer 20 and/or printer 21 so that server 23 may decide whether it would like 
to participate in the data transfer for a number of reasons, such as for security 
purposes. Computer 20 is able to provide server 23 with its own contextual 
information by performing its own instructions to obtain its contextual 
information and passing the information into the Transfer() operation via the 
context parameter. Server 23 may receive data from printer 21 by way of the data 
transfer session object 25 received from computer 20 from printer 21 and 
transferred to server 23 from computer 20 through the Transfer() operation. 

[0055] Next, at step 66 server 23 performs the getTransferData() operation 

included in data transfer session object 25 to retrieve data from printer 21 . The 
data is transferred from printer 21 to server 23 through data transfer session object 
25 at step 68. In this embodiment, one or more of computer 20, printer 21 or 
server 23 may access and perform the abort() operation, fail() operation or the 
completeO operation described above and included in the data transfer session 
object 25. Also, one or more of computer 20, printer 21 or server 23 may be held 
responsible for renewing the leased data transfer session. In another embodiment, 
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one or more of computer 20, printer 21 or server 23 may register as a listener with 
each other by invoking the notification interface (not illustrated) associated with 
computer 20, printer 21 or server 23 to receive event notifications, as described 
above. In this example, computer 20 may invoke the notification interface 
associated with printer 21 and/or server 22 to register as a listener to monitor the 
progress of the data transfer. During the data transfer session between printer 21 
and server 22 the participation of computer 20 is not required. Whether or not 
computer 20 continues to participate in the data transfer session depends upon 
several factors, such as whether computer 20 would like to receive event 
notifications associated with the data transfer sessions and whether computer 20 is 
responsible for renewing the leased data transfer session, as described above. 

[0056] In another embodiment, any one of computer 20, printer 21 or 

server 23 may serve as data sources and data sinks between each other employing 
one or more of the above-described embodiments. For instance, computer 20 may 
initiate a data transfer where server 23 serves as a data source and thus transmits 
data to printer 21 via data object transfer session 25 following the same steps as 
described above with respect to printer 21 transmitting data to server 23. 

[0057] While devices such as computer 20, printer 2 1 , PDA 22, server 23 

and facsimile machine 24 (i.e., components 20-24) have been used as examples in 
one or more embodiments described above, a number of other systems may be 
used as components 20-24 such as software services, applications or portions 
thereof including language translation services, data format converters, e-mail 
applications, calendar applications, or a spell checking routine executing within a 
word processing application. For instance, a word processor could make currently 
selected text available as a data source component so that it could be sent to PDA 
22, which is a data sink component. 

[0058] Other modifications of the present invention may occur to those 

skilled in the art subsequent to a review of the present application, and these 
modifications, including equivalents thereof, are intended to be included within 
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the scope of the present invention. Further, the recited order of processing 
elements or sequences, or the use of numbers, letters, or other designations 
therefor, is not intended to limit the claimed processes to any order except as 
be specified in the claims. 



